Dynamic Assignment of Traffic Classes to a Priority Queue in a Packet Forwarding Device

ABSTRACT

Responsive to detecting a predetermined time of day, packet forwarding treatment is changed in accordance with at least one class of packet flow from a first packet forwarding treatment to a second packet forwarding treatment.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority under 35 U.S.C. §119(e) fromprovisional application Ser. No. 60/226,787, and is related to U.S.patent application Ser. No. 09/227,389, both applications beingincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to the field of telecommunications, andmore particularly to dynamic assignment of traffic classes to queueshaving different priority levels.

BACKGROUND OF THE INVENTION

The flow of packets through packet-switched networks is controlled byswitches and routers that forward packets based on destinationinformation included in the packets themselves. A typical switch orrouter includes a number of input/output (I/O) modules connected to aswitching fabric, such as a crossbar or shared memory switch. In someswitches and routers, the switching fabric is operated at a higherfrequency than the transmission frequency of the I/O modules so that theswitching fabric may deliver packets to an I/O module faster than theI/O module can output them to the network transmission medium. In thesedevices, packets are usually queued in the I/O module to awaittransmission.

One problem that may occur when packets are queued in the I/O module orelsewhere in a switch or router is that the queuing delay per packetvaries depending on the amount of traffic being handled by the switch.Variable queuing delays tend to degrade data streams produced byreal-time sampling (e.g., audio and video) because the original timedelays between successive packets in the stream convey the samplinginterval and are therefore needed to faithfully reproduce the sourceinformation. Another problem that results from queuing packets in aswitch or router is that data from a relatively important source, suchas a shared server, may be impeded by data from less important sources,resulting in bottlenecks.

SUMMARY OF THE INVENTION

A method and apparatus for dynamic assignment of classes of traffic to apriority queue are disclosed. Bandwidth consumption by one or more typesof packet traffic received in a packet forwarding device is monitored.The queue assignment of at least one type of packet traffic isautomatically changed from a queue having a first priority to a queuehaving a second priority if the bandwidth consumption exceeds thethreshold.

Other features and advantages of the invention will be apparent from theaccompanying drawings and from the detailed description that followsbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings in which likereferences indicate similar elements and in which:

FIG. 1 illustrates a packet forwarding device that can be used toimplement embodiments of the present invention;

FIG. 2A illustrates queue fill logic implemented by a queue manager in aquad interface device, and FIG. 2B illustrates queue drain logicaccording to one embodiment;

FIG. 3 illustrates the flow of a packet within the switch of FIG. 1;

FIG. 4 illustrates storage of an entry in an address resolution tablemanaged by an address resolution unit;

FIG. 5 is a diagram of the software architecture of the switch of FIG. 1according to one embodiment; and

FIG. 6 illustrates an example of dynamic assignment of traffic classesto a priority queue.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENTS

A packet forwarding device in which selected classes of network trafficmay be dynamically assigned for priority queuing is disclosed. In oneembodiment, the packet forwarding device includes a Java virtual machinefor executing user-coded Java applets received from a network managementserver (NMS). A Java-to-native interface (JNI) is provided to allow theJava applets to obtain error information and traffic statistics from thedevice hardware and to allow the Java applets to write configurationinformation to the device hardware, including information that indicateswhich classes of traffic should be queued in priority queues. The Javaapplets implement user-specified traffic management policies based onreal-time evaluation of the error information and traffic statistics toprovide dynamic control of the priority queuing assignments. These andother aspects and advantages of the present invention are describedbelow.

It should be noted that the use of the Java language is not arequirement for practicing the present invention. Although Java providesa number of advantages when used to implement the present invention,e.g., dynamic on-demand use, other programming languages such as C maybe used in its place.

FIG. 1 illustrates a packet forwarding device 17 that can be used toimplement embodiments of the present invention. For the purposes of thepresent description, the packet forwarding device 17 is assumed to be aswitch that switches packets between ingress and egress ports based onmedia access control (MAC) addresses within the packets. In an alternateembodiment, the packet forwarding device 17 may be a router that routespackets according to destination internet protocol (IP) addresses or arouting switch that performs both MAC address switching and IP addressrouting. The techniques and structures disclosed herein are applicablegenerally to a device that forwards packets in a packet switchingnetwork. Also, the term packet is used broadly herein to refer to afixed-length cell, a variable length frame or any other informationstructure that is self-contained as to its destination address.

The switch 17 includes a switching fabric 12 coupled to a plurality ofI/O units (only I/O units 1 and 16 are depicted) and to a processingunit 10. The processing unit includes at least a processor 31 (which maybe a microprocessor, digital signal processor or microcontroller)coupled to a memory 32 via a bus 33. In one embodiment, each I/O unit 1,16 includes four physical ports P1-P4 coupled to a quad media accesscontroller (QMAC) 14A, 14B via respective transceiver interface units21A-24A, 21B-24B. Each I/O unit 1, 16 also includes a quad interfacedevice (QID) 16A, 16B, an address resolution unit (ARU) 15A, 15B and amemory 18A, 18B, interconnected as shown in FIG. 1. Preferably, theswitch 17 is modular with at least the I/O units 1, 16 being implementedon port cards (not shown) that can be installed in a backplane (notshown) of the switch 17. In one implementation, each port card includesa given number of I/O units and therefore supports a correspondingnumber of physical ports. The switch backplane includes slots for agiven number of port cards, so that the switch 17 can be scaledaccording to customer needs to support a number of physical ports ascontrolled by the number of port cards. In alternate embodiments, eachI/O unit 1, 16 may support more or fewer physical ports each port cardmay support more or fewer I/O units 1, 16 and the switch 17 may supportmore or fewer port cards. For example, the I/O unit 1 shown in FIG. 1may be used to support 0baseT transmission lines (i.e., 10 Mbps(mega-bit per second), twisted-pair) or 00baseF transmission lines (100Mbps, fiber optic), while a different I/O unit (not shown) may be usedto support a 1000baseF transmission line (1000 Mbps, fiber optic).Nothing disclosed herein should be construed as limiting embodiments ofthe present invention to use with a particular transmission medium, I/Ounit, port card or chassis configuration.

Still referring to FIG. 1, when a packet 25 is received on physical portP1, it is supplied to the corresponding physical transceiver 21A whichperforms any necessary signal conditioning (e.g. optical to electricalsignal conversion) and then forwards the packet 25 to the QMAC 14A. TheQMAC 14A buffers packets received from the physical transceivers 21A-24Aas necessary, forwarding one packet at a time to the QID 16A. Receivelogic within the QID 16A notifies the ARU 15A that the packet 25 hasbeen received. The ARU computes a table index based on the destinationMAC address within the packet 25 and uses the index to identify an entryin a forwarding table that corresponds to the destination MAC address.In packet forwarding devices that operate on different protocol layersof the packet (e.g., routers), a forwarding table may be indexed basedon other destination information contained within the packet.

According to one embodiment, the forwarding table entry identified basedon the destination MAC address indicates the switch egress port to whichthe packet 25 is destined and also whether the packet is part of aMAC-address based virtual local area network (VLAN), or a port-basedVLAN. (As an aide a VLAN is a logical grouping of MAC addresses (aMAC-address-based VLAN) or a logical grouping of physical ports (aport-based VLAN).) The forwarding table entry further indicates whetherthe packet 25 is to be queued in a priority queue in the I/O unit thatcontains the destination port. As discussed below, priority queuing maybe specified based on a number of conditions, including, but not limitedto, whether the packet is part of a particular IP flow, or whether thepacket is destined for a particular port, VLAN or MAC address.

According to one embodiment, the QID 16A, 16B segments the packet 25into a plurality of fixed-length cells 26 for transmission through theswitching fabric 12. Each cell includes a header 28 that identifies itas a constituent of the packet 25 and that identifies the destinationport for the cell (and therefore for the packet 25). The header 28 ofeach cell also includes a bit 29 indicating whether the cell is thebeginning cell of a packet and also a bit 30 indicating whether thepacket 25 to which the cell belongs is to be queued in a priority queueor a best effort queue on the destined I/O unit.

The switching fabric 12 forwards each cell to the I/O unit indicated bythe cell header 28. In the exemplary data flow shown in FIG. 1, theconstituent cells 26 of the packet 25 are assumed to be forwarded to I/Ounit 16 where they are delivered to transmit logic within the QID 16B.The transmit logic in the QID 16B includes a queue manager (not shown)that maintains a priority queue and a best effort queue in the memory18B. In one embodiment, the memory 18B is resolved into a pool ofbuffers, each large enough to hold a complete packet. When the beginningcell of the packet 25 is delivered to the QID 16B, the queue managerobtains a buffer from the pool and appends the buffer to either thepriority queue or the best effort queue according to whether thepriority bit 30 is set in the beginning cell. In one embodiment, thepriority queue and the best effort queue we each implemented by a linkedlist, with the queue manager maintaining respective pointers to the headand tail of each linked list. Entries are added to the tail of the queuelist by advancing the tail pointer to point to a newly allocated bufferthat has been appended to the linked list, and entries are popped offthe head of the queue by advancing the head pointer to point to the nextbuffer in the linked list and returning the spent buffer to the pool.

After a buffer is appended to either the priority queue or the besteffort queue, the beginning cell and subsequent cells are used toreassemble the packet 25 within the buffer. Eventually the packet 25 ispopped off the head of the queue and delivered to an egress port via theQMAC 14B and the physical transceiver (e.g., 23B) in an egressoperation. This is shown by way of example in FIG. 1 by the egress ofpacket 25 from physical port P3 of I/O unit 16.

FIG. 2A illustrates queue fill logic implemented by the queue manager inthe QID. Starting at block 51, a cell is received in the QID from theswitching fabric. The beginning cell bit in the cell header is inspectedat decision block 53 to determine if the cell is the beginning cell of apacket. If so, the priority bit in the cell header is inspected atdecision block 55 to determine whether to allocate an entry in thepriority queue or the best effort queue for packet reassembly. If thepriority bit is set, an entry in the priority queue is allocated atblock 57 and the priority queue entry is associated with the portion ofthe cell header that identifies the cell as a constituent of aparticular packet at block 59. If the priority bit in the cell header isnot set, then an entry in the best effort queue is allocated at block 61and the best effort queue entry is associated with the portion of thecell header that identifies the cell as a constituent of a particularpacket at block 63.

Returning to decision block 53, if the beginning cell bit in the cellheader is not set, then the queue entry associated with the cell headeris identified at block 65. The association between the cell header andthe queue entry identified at block 65 was established earlier in eitherblock 59 or block 63. Also, identification of the queue entry in block65 may include inspection of the priority bit in the cell to narrow theidentification effort to either the priority queue or the best effortqueue. In block 67, the cell is combined with the preceding cell in thequeue entry in a packet reassembly operation. If the reassemblyoperation in block 67 results in a completed packet (decision block 69),then the packet is marked as ready for transmission in block 71. In oneembodiment, the packet is marked by setting a flag associated with thequeue entry in which the packet has been reassembled. Other techniquesfor indicating that a packet is ready for transmission may be used inalternate embodiments.

FIG. 2B illustrates queue drain logic according to one embodiment. Atdecision block 75, the entry at the head of the priority queue isinspected to determine if it contains a packet ready for transmission.If so, the packet is transmitted at block 77 and the correspondingpriority queue entry is popped off the head, of the priority queue anddeallocated at block 79. If a ready packet is not present at the head ofthe priority queue, then the entry at the head of the best effort queueis inspected at decision block 81. If a packet is ready at the head ofthe best effort queue, it is transmitted at block 83 and thecorresponding best effort queue entry is popped off the head of the besteffort queue and deallocated in block 85. Note that, in the embodimentillustrated in FIG. 2B, packets are drained from the best effort queueonly after the priority queue has been emptied. In alternateembodiments, a timer, counter or similar logic element may be used toensure that the best effort queue 105 is serviced at least every sooften or at least after every N number of packets are transmitted fromthe priority queue, thereby ensuring at least a threshold level ofservice to best effort queue.

FIG. 3 illustrates the flow of a packet within the switch 17 of FIG. 1.A packet is received in the switch at block 91 and used to identify anentry in a forwarding table called the address resolution (AR) table atblock 93. At decision block 95, a priority bit in the AR table entry isinspected to determine whether the packet belongs to a class of trafficthat has been selected for priority queuing. If the priority bit is set,the packet is segmented into cells having respective priority bits setin their headers in block 97. If the priority bit is not set, the packetis segmented into cells having respective priority bits cleared theircell headers in block 99. The constituent cells of each packet areforwarded to an egress I/O unit by the switching fabric. In the egressI/O unit, the priority bit of each cell is inspected (decision block101) and used to direct the cell to an entry in either the priorityqueue 103 or the best effort queue 105 where it is combined with othercells to reassemble the packet.

FIG. 4 illustrates storage of an entry in the address resolution (AR)table managed by the ARU. In one embodiment, the AR table is maintainedin a high speed static random access memory (SRAM) coupled to the ARU.Alternatively, the AR table may be included in a memory within anapplication-specific integrated circuit (ASIC) that includes the ARU.Generally, the ARU stores an entry in the AR table in response to packetforwarding information from the processing unit. The processing unitsupplies packet forwarding information to be stored in each AR table inthe switch whenever a new association between a destination address anda switch egress port is learned. In one embodiment, an address-to-portassociation is learned by transmitting a packet that has an unknownegress port assignment on each of the egress ports of the switch andassociating the destination address of the packet with the egress portat which an acknowledgment is received. Upon learning the associationbetween the egress port and the destination address, the processing unitissues forwarding information that includes, for example, an identifierof the newly associated egress port, the destination MAC address, anidentifier of the VLAN associated with the MAC address (if any), anidentifier of the VLAN associated with the egress port (if any), thedestination IP address the destination IP port (e.g., transmissioncontrol protocol (TCP), universal device protocol (UDP) or other IPport) and the IP protocol (e.g., HTTP, FTP or other IP protocol). Thesource IP address, source IP port and source IP protocol may also besupplied to fully identify an end-to-end IP flow.

Referring to FIG. 4, forwarding information 110 is received from theprocessing unit at block 115. At block 117, the ARU stores theforwarding information in an AR table entry. At decision block 119, thephysical egress port identifier stored in the AR table entry is comparedagainst priority configuration information to determine if packetsdestined for the egress port have been selected for priority egressqueuing. If so, the priority bit is set in the AR table entry in block127. Thereafter, incoming packets that index the newly stored tableentry will be queued in the priority queue to await transmission. Ifpackets destined for the egress port have not been selected for priorityqueuing, then at decision block 121 the MAC address stored in the ARtable entry is compared against the priority configuration informationto determine if packets destined for the MAC address have been selectedfor priority egress queuing. If so, the priority bit is set in the ARtable entry in block 127. If packets destined for the MAC address havenot been selected for priority egress queuing, then at decision block123 the VLAN identifier stored in the AR table entry (if present) iscompared against the priority configuration information to determine ifpackets destined for the VLAN have been selected for priority egressqueuing. If so, the priority bit is set in the AR table entry in block127. If packets destined for the VLAN have not been selected forpriority egress queuing, then at block 125 the IP flow identified by theIP address, IP port and IP protocol in the AR table is compared againstthe priority configuration information to determine if packets that formpart of the IP flow have been selected for priority egress queuing. Ifso, the priority bit is set in the AR table entry, otherwise thepriority bit is not set. Yet other criteria may be considered inassigning priority queuing in alternate embodiments. For example,priority queuing may be specified for a particular IP protocol (e.g.FTP, HTTP). Also, the ingress port, source MAC address or source VLAN ofa packet may also be used to determine whether to queue the packet inthe priority egress packet. More specifically, in one embodiment,priority or best effort queuing of unicast traffic is determined basedon destination parameters (e.g., egress port, destination MAC address ordestination IP address), while priority or best effort queuing ofmulticast traffic is determined based on source parameters (e.g.,ingress port source MAC address or source IP address).

FIG. 5 is a diagram of the software architecture of the switch 17 ofFIG. 1 according to one embodiment. An operating system 143 and devicedrivers 145 are provided to interface with the device hardware 141. Forexample, device drivers are provided to write configuration informationand AR storage entries to the ARUs in respective I/O units. Also, theoperating system 143 performs memory management functions and othersystem services in response to requests from higher level software.Generally, the device drivers 145 extend the services provided by theoperating system and are invoked in response to requests for operatingsystem service that involve device-specific operations.

The device management code 147 is executed by the processing unit (e.g.,element 10 of FIG. 1) to perform system level functions, includingmanagement of forwarding entries in the distributed AR tables andmanagement of forwarding entries in a master forwarding table maintainedin the memory of the processing unit. The device management code 147also includes routines for invoking device driver services, for example,to query the ARU for traffic statistics and error information, or towrite updated configuration information to the ARUs, including priorityqueuing information. Further, the device management code 147 includesroutines for writing updated configuration information to the ARUs, asdiscussed below in reference to FIG. 6. In one implementation, thedevice management code 147 is native code, meaning that the devicemanagement code 147 is a compiled set of instructions that can beexecuted directly by a processor in the processing unit to carry out thedevice management functions.

In one embodiment, the device management code 147 supports the operationof a Java client 160 that includes a number of Java applets, including amonitor applet 157, a policy enforcement applet 159 and configurationapplet 161. A Java applet is an instantiation of a Java class thatincludes one or more methods for self initialization (e.g., aconstructor method called “Applet( )”), and one or more methods forcommunicating with a controlling application. Typically the controllingapplication for a Java applet is a web browser executed on a generalpurpose computer. In the software architecture shown in FIG. 5, however,a Java application called Data Communication Interface (DCI) 153 is thecontrolling application for the monitor, policy enforcement andconfiguration applets 157, 159, 161. The DCI application 153 is executedby a Java virtual machine 149 to manage the download of Java appletsfrom a network management server (NMS) 170. A library of Java objects155 is provided for use by the Java applets 157, 159, 161 and the DCIapplication 153.

As above, it should be noted that the use of Java is not essential tothe present invention and is used for purposes of illustration andexplanation. Other programming languages may be used in its place.

In one implementation, the NMS 170 supplies Java applets to the switch17 in a hyper-text transfer protocol (HTTP) data stream. Other protocolsmay also be used. The constituent packets of the HTTP data stream areaddressed to the IP address of the switch and are directed to theprocessing unit after being received by the I/O unit coupled to the NMS170. After authenticating the HTTP data stream, the DCI application 153stores the Java applets provided in the data stream in the memory of theprocessing unit and executes a method to invoke each applet. An appletis invoked by supplying the Java virtual machine 149 with the address ofthe constructor method of the applet and causing the Java virtualmachine 149 to begin execution of the applet code. Program code definingthe Java virtual machine 149 is executed to interpret the platformindependent byte codes of the Java applets 157, 159, 161 into nativeinstructions that can be executed by a processor within the processingunit.

According to one embodiment, the monitor applet 157, policy enforcementapplet 159 and configuration applet 161 communicate with the devicemanagement code 147 through a Java-native interface (JNI) 151. The JNI151 is essentially an application programming interface (API) andprovides a set of methods that can be invoked by the Java applets 157,159, 161 to send messages and receive responses from the devicemanagement code 147. In one implementation, the JNI 151 includes methodsby which the monitor applet 157 can request the device management code147 to gather error information and traffic statistics from the devicehardware 141. The JNI 151 also includes methods by which theconfiguration applet 161 can request the device management code 147 towrite configuration information to the device hardware 141. Morespecifically, the JNI 151 includes a method by which, the configurationapplet 161 can indicate that priority queuing should be performed forspecified classes of traffic, including, but not limited to, the classesof traffic discussed above in reference to FIG. 4. In this way, auser-coded configuration applet 161 may be executed by the Java virtualmachine 149 within the switch 17 to invoke a method in the JNI 151 torequest the device management code 147 to write information that assignsselected classes of traffic to be queued in the priority egress queue.In effect, the configuration applet 161 assigns virtual queues definedby the selected classes of traffic to feed into the priority egressqueue.

As noted above, although a Java virtual machine 149 and Java applets157, 159, 161 have been described, other virtual machines, interpretersand scripting languages may be used in alternate embodiments, Also, asdiscussed below, more or fewer Java applets may be used to perform themonitoring, policy enforcement and configuration functions in alternateembodiments.

FIG. 6 illustrates an example of dynamic assignment traffic classes to apriority queue. An exemplary network includes switches A and B coupledtogether at physical ports 32 and 1, respectively. Suppose that anetwork administrator or other user determines that an important server175 on port 2 of switch A requires a relatively high quality of service(QoS), and that, at least in switch B, the required QoS can be providedby ensuring that at least 20% of the egress capacity of switch B, port 1is reserved for traffic destined to the MAC address of the server 175.One way to ensure that 20% egress capacity is reserved to trafficdestined for the server 175 is to assign priority queuing for packetsdestined to the MAC address of the server 175, but not for othertraffic. While such an assignment would ensure priority egress to theserver traffic, it also may result in unnecessarily high bandwidthallocation to the server 175, potentially starving other importanttraffic or causing other important traffic to become bottlenecked behindless important traffic in the best effort queue. For example, supposethat there are at least two other MAC address destinations, MAC addressA and MAC address B, to which the user desires to assign priorityqueuing, so long as the egress capacity required by the server-destinedtraffic is available. In that case, it would be desirable to dynamicallyconfigure the MAC address A and MAC address B traffic to be queued ineither the priority queue or the best effort queue according to existingtraffic conditions. In at least one embodiment, this is accomplishedusing monitor, policy enforcement and configuration applets that havebeen downloaded to switch B and which are executed in a Java client inswitch B as described above in reference to FIG. 5.

FIG. 6 includes exemplary pseudocode listings of monitor, policyenforcement and configuration applets 178, 179, 180 that can be used toensure that at least 20% of the egress capacity of switch B, port 1 isreserved for traffic destined to the server 175, but withoutunnecessarily denying priority queuing assignment to traffic destinedfor MAC addresses A and B. Ater initialization, the monitor applet 178repeatedly measures of the port 1 line utilization from the devicehardware. In one embodiment, the ARU in the I/O unit that manages port 1keeps a count of the number of packets destined for particular egressports, packets destined for particular MAC addresses, packets destinedfor particular VLANS, packets that form part of a particular IP low,packets having a particular IP protocol, and so forth. The ARU alsotracks the number of errors associated with these different classes oftraffic, the number of packets from each class of traffic that aredropped, and other statistics. By determining the change in thesedifferent statistics per unit time, a utilization factor may begenerated that represents the percent utilization of the capacity of anegress port, an I/O unit or the overall switch. Error rates and packetdrop rates may also be generated.

In one embodiment, the monitor applet 178 measures line utilization byinvoking methods in the JNI to read the port 1 line utilizationresulting from traffic destined for MAC address A and for MAC address Bon a periodic basis, e.g., every 10 milliseconds.

The policy enforcement applet 179 includes variables to hold the lineutilization percentage of traffic destined for MAC address A (A %), theline utilization percentage of traffic destined for MAC address B (B %),the queue assignment (i.e., priority or best effort) of traffic destinedfor the server MAC address (QA_S), the queue assignment of trafficdestined for MAC address A (QA_A) and the queue assignment of trafficdestined for MAC address B. Also, a constant, DELTA, is defined to be 5%and the queue assignments for the MAC address A, MAC address B andserver MAC address traffic are initially set to the priority queue.

The policy enforcement applet 179 also includes a forever loop in whichthe line utilization percentages A % and B % are obtained from themonitor applet 178 and used to determine whether to change the queueassignments QA_A and QA_B. If the MAC address A traffic and the MACaddress B traffic are both assigned to the priority queue (the initialconfiguration) and the sum of the line utilization percentages A % and B% exceeds 80%, then less than 20% line utilization remains for thesaver-destined traffic. In that event, the MAC address A traffic isreassigned from the priority queue to the best effort queue (codestatement 181). If the MAC address A traffic is assigned to the besteffort queue and the MAC address B traffic is assigned to the priorityqueue, then the MAC address A traffic is reassigned to the priorityqueue if the sum of the line utilization percentages A % and B % dropsbelow 80% less DELTA (code statement 183). The DELTA parameter providesa deadband to prevent rapid changing of priority queue assignment.

If the MAC address A traffic is assigned to the best effort queue andthe MAC address B traffic is assigned to the priority queue and the lineutilization percentage B % exceeds 80%, then less than 20% lineutilization remains for the server-destined traffic. Consequently, theMAC address B traffic is reassigned from the priority queue to the besteffort queue (code statement 185). If the MAC address B traffic isassigned to the best effort queue and the line utilization percentage B% drops below 80% less DELTA, then the MAC address B traffic isreassigned to the priority queue (code statement 187). Although notspecifically provided for in the exemplary pseudocode listing of FIG. 6,the policy enforcement applet 179 may treat the traffic destined for theMAC A and MAC B addresses more symmetrically by including additionalstatements to conditionally assign traffic destined for MAC address A tothe priority queue, but not traffic destined for MAC address B. In theexemplary pseudocode listing of FIG. 6, the policy enforcement applet179 delays for 5 milliseconds at the end of each pass through theforever loop before repeating.

The configuration applet 180 includes variables, QA_A and QA_B, to holdthe queue assignments of the traffic destined for the MAC addresses Aand B, respectively. Variables LAST_QA_A and LAST_QA_B are also providedto record the history (i.e., most recent values) of the QA_A and QA_Bvalues. The LAST_QA_A and LAST_QA_B variables are initialized toindicate that traffic destined for the MAC addresses A and B is assignedto the priority queue.

Like the monitor and policy enforcement applets 178, 179, theconfiguration applet 180 includes a forever loop in which a codesequence is executed followed by a delay, in the exemplary listing ofFIG. 6, the first operation performed by the configuration applet 180within the forever loop is to obtain the queue assignments QA_A and QA_Bfrom the policy enforcement applet 179. If the queue assignmentindicated by QA_A is different from the queue assignment indicated byLAST_QA_A, then a JNI method is invoked to request the device code toreconfigure the queue assignment of the traffic destined for MAC addressA according to the new QA_A value. The new QA_A value is then copiedinto the LAST_QA_A variable so that subsequent queue assignment changesare detected. If the queue assignment indicated by QA_B is differentfrom the queue assignment indicated by LAST_QA_B, then a JNI method isinvoked to request the device code to reconfigure the queue assignmentof the traffic destined for MAC address B according to the new QA_Bvalue. The new QA_B value is then copied into the LAST_QA_B variable sothat subsequent queue assignment changes are detected. By thisoperation, and the operation of the monitor and policy enforcementapplets 178, 179, traffic destined for the MAC addresses A and B isdynamically assigned to the priority queue according to real-timeevaluations of the traffic conditions in the switch.

Although a three-applet implementation is illustrated in FIG. 6, more orfewer applets may be used in an alternate embodiment. For example, thefunctions of the monitor, policy enforcement and configuration applets178, 179, 180 may be implemented in a single applet. Alternatively,multiple applets may be provided to perform policy enforcement or otherfunctions using different queue assignment criteria. For example, onepolicy enforcement applet may make priority queue assignments based ondestination MAC addresses, while another policy enforcement applet makespriority queue assignments based on error rates or line utilization ofhigher level protocols. Multiple monitor applets or configurationapplets may similarly be provided.

Although queue assignment policy based on destination MAC address isillustrated in FIG. 6, myriad different queue assignment criteria may beused in other embodiments. For example, instead of monitoring andupdating queue assignment based on traffic to destination MAC addresses,queue assignments may be updated on other traffic patterns, includingtraffic to specified destination ports, traffic from specified sourceports, traffic from specified source MAC addresses, traffic that formspart of a specified IP flow, traffic that is transmitted using aspecified protocol (e.g., HTTP, FTP or other protocols) and so forth.Also, queue assignments may be updated based on environmental conditionssuch as time of day, changes in network configuration (e.g., due tofailure or congestion at other network nodes), error rates, packet droprates and so forth. Monitoring, policy enforcement and configurationapplets that combine many or all of the above-described criteria may beimplemented to provide sophisticated traffic handling capability in apacket forwarding device.

Although dynamic assignment of traffic classes to a priority egressqueue has been emphasized, the methods and apparatuses described hereinmay alternatively be used to assign traffic classes to a hierarchicalset of queues anywhere in a packet forwarding device including, but notlimited to, ingress queues and queues associated with delivering andreceiving packets from the switching fabric. Further, although the queueassignment of traffic classes has been described in terms of a pair ofqueues (priority and best effort), additional queues in a prioritizationhierarchy may be used without departing from the spirit and scope of thepresent invention.

Further, although the modification of various queues in this way hasbeen described herein, the invention is not so limited and otherembodiments also exist. For example, traffic can be filtered based onits type—source (e.g., source MAC address or source VLAN), ingress port,destination (e.g., destination. MAC address or destination IP address),egress port, protocol (e.g., FTP, HTTP) or other hardware-supportedfilters. In one embodiment, filtering of unicast traffic is determinedbased on destination parameters such as egress port, destination MACaddress or IP address, while filtering of multicast traffic isdetermined based on source parameters such as ingress port, source MACaddress or source IP address.

Filtering may be based on environmental conditions, such as time of day,changes in network configuration (e.g., due to failure or congestion atother network nodes), error rates, packet drop rates, line utilizationof higher-level protocols. It may be based on traffic patterns such astraffic from specified source ports, traffic to specified destinationports, traffic from specified source MAC addresses or traffic that formspart of a specified IP flow. Various other hardware counters, monitorsand dynamic values can be read from the hardware.

Still further, dynamic filtering decisions may be made on how to processpackets other than choosing whether they should go to a priority or besteffort queue; for example, they may be dropped or copied, or traffic ofa specific type as described above may be diverted. Packet headers maybe modified, and use of differentiated services (DS), quality of service(QoS), TOS, TTL, destination and the like is possible as long as it issupported by the hardware. The configurability of filtering andsubsequent processing in the invention is, in fact, limited only by thehardware and numerous possibilities for filtering and subsequentprocessing of traffic other than those described herein will be readilyapparent to those skilled in the art after reading and understandingthis application.

As an example, consider the routing of multimedia traffic. Such trafficmight be sent by three or more separated streams defined by, e.g.,virtual port number. This traffic could be filtered and processed todynamically add or drop specific streams. Based on such dynamicadaptation, active network applications on nodes between the source anddestination can negotiate and dynamically set different adaptationmechanisms. As described above, the invention is of course not limitedto this example, and in fact is intended to cover such filtering andprocessing using future hardware platforms which provide newcapabilities and which afford new ways of using and controlling suchfunctionality.

In the foregoing specification, the invention has been described withreference to specific exemplary embodiments thereof It will, however, beevident that various modifications and changes may be made to thespecific exemplary embodiments without departing from the broader spiritand scope of the invention as set forth in the appended claims.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

1. In a packet forwarding device in a network in which packet flows are assigned respective classes and each respective class is accorded a respective packet forwarding treatment, a method comprising: detecting a predetermined time of day; and responsive to detecting the predetermined time of day, changing the respective packet forwarding treatment accorded to at least one class of packet flow from a first packet forwarding treatment to a second packet forwarding treatment.
 2. The method of claim 1, wherein changing the respective packet flow treatment accorded to the at least one class of packet flow comprises changing assignment of the at least one class of packet flow from a queue having a first priority to a queue having a second priority.
 3. The method of claim 1, wherein changing the respective packet flow treatment accorded to the at least one class of packet flow comprises dropping packets of the at least one class of packet flow.
 4. The method of claim 1, wherein changing the respective packet flow treatment accorded to the at least one class of packet flow comprises copying packets of the at least one class of packet flow.
 5. The method of claim 1, wherein changing the respective packet flow treatment accorded to the at least one class of packet flow comprises diverting packets of the at least one class of packet flow.
 6. The method of claim 1, wherein a packet flow is assigned a respective class based on at least one IP flow parameter of the packet flow.
 7. The method of claim 1, wherein a packet flow is assigned a respective class based on a respective source of the packet flow.
 8. The method of claim 7, wherein the packet flow is assigned the respective class based on a MAC address of the source of the packet flow.
 9. The method of claim 7, wherein the packet flow is assigned the respective class based on a VLAN associated with the source of the packet flow.
 10. The method of claim 1, wherein a packet flow is assigned a respective class based on a destination of the packet flow.
 11. The method of claim 10, wherein the packet flow is assigned a respective class based on a MAC address of the destination of the packet flow.
 12. The method of claim 10, wherein the packet flow is assigned the respective class based on a VLAN associated with the destination of the packet flow.
 13. The method of claim 1, wherein the packet flow is assigned a respective class based on an ingress port associated with the packet flow.
 14. The method of claim 1, wherein the packet flow is assigned a respective class based on an egress port associated with the packet flow.
 15. The method of claim 1, wherein the packet flow is assigned a respective class based on a virtual port associated with the packet flow.
 16. The method of claim 1, wherein a packet flow is assigned a respective class based on a protocol of the packet flow.
 17. The method of claim 16, wherein a packet flow is assigned a respective class based on whether is associated with a specified high level protocol.
 18. The method of claim 17, wherein a packet flow is assigned a respective class if it is associated with an FTP flow.
 19. The method of claim 17, wherein the packet flow is assigned a respective class if it is associated with an HTTP flow.
 20. The method of claim 1, wherein a packet flow is assigned a respective class based on a traffic type of the of the packet flow.
 21. The method of claim 1, wherein a packet flow is assigned a respective class based on whether it is associated with a specified IP flow.
 22. A non-transitory, processor-readable medium carrying instructions for execution by at least one processor, the instructions comprising instructions executable in a packet forwarding device in a network in which packet flows are assigned respective classes and each respective class is accorded a respective packet forwarding treatment, the instructions comprising: instructions executable to detect a predetermined time of day; and instructions executable responsive to detecting the predetermined time of day, to change the respective packet forwarding treatment accorded to at least one class of packet flow from a first packet forwarding treatment to a second packet forwarding treatment.
 23. The medium of claim 22, wherein the instructions executable to change the respective packet flow treatment accorded to the at least one class of packet flow comprise instructions executable to change assignment of the at least one class of packet flow from a queue having a first priority to a queue having a second priority.
 24. The medium of claim 22, wherein the instructions executable to change the respective packet flow treatment accorded to the at least one class of packet flow comprise instructions executable to drop packets of the at least one class of packet flow.
 25. The medium of claim 22, wherein the instructions executable to change the respective packet flow treatment accorded to the at least one class of packet flow comprise instructions executable to copy packets of the at least one class of packet flow.
 26. The medium of claim 22, wherein the instructions executable to change the respective packet flow treatment accorded to the at least one class of packet flow comprise instructions executable to divert packets of the at least one class of packet flow.
 27. The medium of claim 22, wherein the instructions comprise instructions executable to assign a packet flow a respective class based on at least one IP flow parameter of the packet flow.
 28. The medium of claim 22, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a respective source of the packet flow.
 29. The medium of claim 28, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a MAC address of the source of the packet flow.
 30. The medium of claim 28, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a VLAN associated with the source of the packet flow.
 31. The medium of claim 22, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a destination of the packet flow.
 32. The medium of claim 31, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a MAC address of the destination of the packet flow.
 33. The medium of claim 31, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a VLAN associated with the destination of the packet flow.
 34. The medium of claim 22, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on an ingress port associated with the packet flow.
 35. The medium of claim 22, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on an egress port associated with the packet flow.
 36. The medium of claim 22, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a virtual port associated with the packet flow.
 37. The medium of claim 22, wherein the instructions comprise instructions executable to assign a respective class to a packet flow based on a protocol of the packet flow.
 38. The medium of claim 37, wherein a packet flow is assigned a respective class based on whether is associated with a specified high level protocol.
 39. The medium of claim 38, wherein the instructions executable to assign a respective class to the packet flow based on the protocol of the packet flow comprise instructions executable to assign the packet flow the respective class if it is associated with an FTP flow.
 40. The medium of claim 38, wherein the instructions executable to assign a respective class to the packet flow based on the protocol of the packet flow comprise instructions executable to assign the packet flow the respective class if it is associated with an HTTP flow.
 41. The medium of claim 22, comprising instructions executable to assign a packet flow a respective class based on a traffic type of the of the packet flow.
 42. The medium of claim 22, wherein a packet flow is assigned a respective class based on whether it is associated with a specified IP flow. 